What does "not mandatory for a high performance implementation" mean? RISC-V extensions do not specify whether they are mandatory or not. That is the job of separate documents.

Note: performace is misspelled.

This was formulated to distinguish the extra vector crypto extension from the vector crypto extension itself.
This set of instructions is considered to be an addition to the current vector crypto spec
The vector crypto spec is the main extension implementers and users may want to adopt to get good performance for the supported cryptographic primitives.
These new extensions are additional improvements to the base vector crypto extensions.

I will rephrase this and fix the typo.

What is the "them" in "algorithms that use them"? The new extensions or the existing ones?

it was suppose to be "extra features" so "new extensions".

Well, without the extensions there are no algorithms that use them, so that phrasing is a bit strange. Maybe list some of the specific algorithms that are intended to be improved?

", it" => ". It "

Is there a better name for this? What name will be used for the next set of "extra" extensions? What is the difference between an extra extension and a non-extra extension?

Zfa is using "additional" which may be better here (https://github.com/riscv/riscv-isa-manual/blob/main/src/zfa.adoc).

That document is titled ""Zfa" Standard Extension for Additional Floating-Point Instructions, Version 1.0". That's less ambiguous because it includes the actual extension code Zfa, which won't be reused by any future extension. This document just refers to "Vector Cryptography Extra extensions" as if there will never be any more. Maybe include the actual extension codes in the title?

Good idea, I will update the title to manage room for future "extra"/additional extensions.

Why doesn't Zvkt require that these new instructions be constant-time?

Zvkt will require that these new extensions be constant time, I need to clarify this.
More precisely, Similarly to Zvkg which mandates

To help avoid side-channel timing attacks, these instructions shall be implemented with data-independent timing.

Zvkgs should inherit the same mandate and require constant-time even when Zvkt is not implemented.

Constant time for Zvbc32e will depend on Zvkt.

Maybe "32-bit Vector Carryless Multiplication"?

Also, are there specific use cases in mind where this feature would be useful? #309 mentioned CRC-32, but I'm not sure why that would be true. CRC-32 implementations that use "folding" with carryless multiplication multiply segments of the data by a 32-bit multiplicand, but those segments of data can be any length. Other CPUs (and the currently ratified Zvbc extension) provide 64-bit carryless multiplication, so CRC-32 implementations typically multiply 64 bits of data by a 32-bit multiplier to get a 95-bit result. You could multiply 32 bits of data by a 32-bit multiplier to get a 63-bit result, but that would result in twice as many multiplications being needed to compute the CRC-32, as each one would process half as much data. That probably wouldn't be faster.

A similar observation applies to e.g. CRC-16 where the multiplications are typically 64-bit by 16-bit.

BTW, if adding 32-bit, why not also add 16-bit and 8-bit? What is special about 32?

Those are very good points.
There are multiple considerations at play here.

• 32-bit CLM allows vector implementation with smaller ELEN=32 to implement it (which was not possible for Zvbc)
• 64-bit or 32-bit CLM for folding CRC does not make a performance difference as far as I can tell but should make a power difference. It is true that in folding CRC the data segment block can be of arbitrary length but the constant multiplicand is of the size of the CRC so in the case of a CRC-32 at least half the 64-bit CLM would be unused (which might not be an issue on all micro-arch, but 32-bit CRC should allow easier determination of expected multiplier activity).

And finally there is nothing special about 32-bit. It was initially introduced because of the ELEN=32 case, but we listed in the questions above

Should Zvbc32e support SEW=16 ? (SEW=8 ?)

I think there is a good case for supporting other SEW:

• no need encoding required
• should allow other use cases

If we want to go that route the question is:

• Should we split different SEW support into different sub-extensions (Zvbc16e, Zvbc8e) so people can pick and chose ? I think this might not be such a good idea because I don't expect supporting smaller element width to have a big cost (although I did not measure it yet) and the added complexity of numerous extensions does not seem worth it.

(One of the option which was discarded for the fast track was suggesting a widening CLM to merge vclmul and vclmulh together, but it seems too big of a change to fit into a fast track and the potential impact of having to switch SEW back and forth was not yet properly evaluated on the target use cases).

This is not a complete sentence.

More importantly, it's not clear to me how these vs instructions for GHASH are helpful, because parallelized GHASH requires multiplying by powers of the key (like H, H^2, H^3, H^4, ...). Does that not preclude the use of these vs instructions?

There are multiple different implementations of parallel GHASH.
One implementation on 4 block in paralell uses a vector of 4 constants H^4 in the loop body which could leverage the .vs. It still needs a reduction with H, H^2, H^3 in the loop epilog.

I rephrased things a bit (in the upcoming v0.0.4). The introduction sentence is re-used from https://github.com/riscv/riscv-crypto/blob/main/doc/vector/riscv-crypto-vector-zvkg.adoc.

I need to work on an example of use of these instructions.